Virtual environment manager

ABSTRACT

A virtual environment manager (“VEM”) simplifies the usability of virtual machines and provides users with an enhanced design for creating and/or for managing virtual machines (“VMs”). For example, a user can select description information and management information to be included in descriptors and according to which a VEM will create and manage various VM environments for various host environments. The VEM automatically creates the VM environments and host environments by sending descriptor description information and data files associated with the description information to virtual machine monitors (VMMs), which create the VM environments according to the description information. A VEM at each host may manage VM environments executed by the VMM, according to the descriptor management information. Thus, a set of descriptors to create and manage a set of VMs for a home computer may be easily modified by a user to create and manage a set of VMs for a work or laptop computer.

RELATED APPLICATION

This application is a continuation-in-part (CIP) of pending U.S. patentapplication Ser. No. 11/016,656 filed Dec. 17, 2004 entitled “Method,apparatus, and system for transparent unification of virtual machines.”

FIELD

Embodiments of the invention relate generally to the field of computersystem design for systems having virtual machines (VMs). Moreparticularly, embodiments relate to enhanced description information anda simplified design for provisioning, creating, sharing, and managingvirtual machines.

BACKGROUND

Virtualization technology enables a single host computer running avirtual machine monitor (“VMM”) to present multiple abstractions and/orviews of the host, such that the underlying hardware of the host appearsas one or more independently operating virtual machines (“VMs”). Each VMmay function as a self-contained platform, running its own firmware(“BIOS”), operating system (“OS”) and/or a software application(s). TheVMM manages allocation and virtualization of host resources, andperforms context switching as necessary to cycle between or acrossvarious virtual machines according to a round-robin or other schedulingalgorithms.

Given the complexity and processing requirements of virtualization, thistechnology has typically been available only on workstations, serversand/or mainframes for use by sophisticated users. As processortechnology advances, however, virtualization is being made available inthe desktop environment for use by average users.

As virtualization becomes more commonly available in the desktopenvironment (e.g., a desktop host) the most likely users are unlikely tobe computer professionals (e.g., information technology specialists incorporate environments) but rather less sophisticated users (e.g., homepersonal computer (“PC”) users and/or non-technical, less sophisticatedcorporate users). The applications that run within the desktopenvironment and the types of uses for the applications may also differfrom corporate applications. For example, one use of virtualization in ahome (and the associated advantage of running one or more independentVMs on a host) may be for each family member to be allocated a VMpartition with their own customized environment, e.g., a gaming VMpartition, a Personal Video Recorder (“PVR”) appliance VM, an enterpriseInformation Technology (“IT”) supplied VM for telecommuting, etc.Moreover, it is likely that each user may have several VMs, eachpossibly dedicated for a specific task such as a dedicated VM forinternet browsing, one for gaming applications, one replicating a user'slegacy system (e.g. previously owned PC and SW environment), etc. Somemight be scheduled to run 24×7 (e.g. a personal video recorder (“PVR)),while others are launched and exited frequently. In this environment,the average home PC user may be overwhelmed by the task of understandingand/or managing the VM partitions (e.g., moving files, setting up accesspermissions, etc.).

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of exampleand not limitation in the figures of the accompanying drawings in whichlike references indicate similar elements, and in which:

FIG. 1 illustrates a host computing device having a VEM as a VM;

FIG. 2 illustrates a host computing device having a VEM as part of aVMM;

FIG. 3 illustrates creation of VM environments;

FIG. 4 illustrates a default host environment and a travel hostenvironment for a user;

FIG. 5 illustrates VM environments and host environments running onhosts;

FIG. 6A illustrates VEM denial of access to a resource for a VEM as aVM;

FIG. 6B illustrates VEM denial of access to a resource for a VEM as partof a VMM;

FIG. 7 is a flow chart that conceptually illustrates an example ofcreation and management of VM environments;

FIG. 8 illustrates an example of a unified user interface on the desktopof the VM host according to an embodiment of the present invention;

FIG. 9 illustrates the output from an application running in a VM, asdisplayed on the unified user interface on the desktop on the VM hostaccording to an embodiment of the present invention;

FIG. 10 illustrates a unification console input and output interactionsaccording to an embodiment of the present invention.

DETAILED DESCRIPTION

Reference in the specification to “one embodiment” or “an embodiment” ofthe present invention means that a particular feature, structure orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrases “in one embodiment,” “according to oneembodiment” or the like appearing in various places throughout thespecification are not necessarily all referring to the same embodiment.

Various embodiments of the present invention simplify the usability ofvirtual machines (VMs) and provide users with an enhanced design forcreating virtual machines and/or for managing virtual machines, such asusing a logically unified (monolithic) compute environment. Such adesign may include a system, apparatus, method, scheme, process,software application, description information, data files, and/or thelike. For example, a virtual environment manager (VEM) or a “VEM module”can be used for provisioning of VM environments, sharing VMenvironments, VM environment creations/instantiations, and/or VMenvironment management. This can be useful for propagating monolithicconfigurations to a large set of users, sharing best known environmentsamong family/friends/colleagues, or permitting collaborative workspaces.Also, a VEM may provide creation and management of VM environments forunsophisticated users. In an embodiment a VEM works in collaboration oras an extension to a VMM. In an embodiment a VEM works in collaborationor as an extension to a VM.

The VEM may manage VM environments run or being executed on a VMM bycontinuously monitoring and/or filtering incoming and/or outgoing data(e.g., file requests, network ports/streams (e.g. Hyper Text TransportProtocol (“HTTP”)), files, streams and/or attachments) and makeautomatic determinations regarding how to manage the data (e.g., whereto store files, when and/or whether to deliver the files, execute thefiles, etc.). In one embodiment, the VEM may perform such behaviors,managing, monitoring and/or filtering at “choke points” in and out ofthe VMs running on the VM host (e.g., a VMM host environment), i.e.,points on the VM through which all input/output (I/O) to and from the VMtypically traverse. The term “host” may be used herein to describe ahost environment, such as a VMM environment, a VMM host, a VMM hostenvironment, a host physical environment, or a VM environment run on asingle computing processor for one or more virtual machine environments.Also, a “host” may refer to a single host computer, host machine or hostelectronic device having a processor and a main memory able to run avirtual machine monitor (“VMM”) to present multiple abstractions and/orviews of the host.

In some cases components of a “host” or a “system” supporting orincluding a VEM may include a computer processor (and/or platform) withvirtual-machine (VM) support (i.e. a virtual machine monitor (VMM) inhardware, software, firmware, or a combination thereof). For example,FIG. 1 illustrates a host computing device (“Host 100”) having a VEMhosted in a VM. FIG. 1 shows host 100 (e.g., a VMM host or VMM hostenvironment) including VM 110, 120, and 150 running on VMM 130. Aspreviously described, a virtual-machine monitor (“VMM 130”) typicallyruns on the host platform and presents an abstraction(s) and/or view(s)of the platform (also referred to as “virtual machines” or “VMs”) toother software. Although only three VM partitions are illustrated (“VM110”, “VM 120”, and “VM 150”, hereafter referred to collectively as“VMs”), these VMs are merely illustrative and additional virtualmachines may be added to the host. For instance, in some embodiments,only VM 110 and VM 150 may exist on host 100. Alternatively, in somecases, VMs in addition to VM 110 and VM 120 may exist with VM 150 onhost 100. Additionally, such variations may occur over time for givenhost machine; that is, the number and configuration of VMs running on agiven host may vary over time. VMM 130 may be implemented in software(e.g., as a standalone program and/or a component of a host operatingsystem), hardware, firmware and/or any combination thereof. Forinstance, VMM 130 may be a VMM configuration that stands alone and canhandle devices (e.g., has device drivers, etc.), or, alternatively, isan “OS-hosted” VMM (e.g., such as where the VMM and hosting OScollaborate), or otherwise as known in the art. For an OS-hosted VMM,the VMM may have a driver or some other interface into the OS, and mayrely on the hosting OS for device drivers etc. Also, in some cases, theguest OS's may know they are being virtualized (e.g., a situation thatmay be called paravirtualization), to gain certain efficiencies, etc.Host 100 may be, for example, embodied in a desktop computer, a laptopcomputer, a hand held computing device, a personal computer (PC), acomputer server, a computer that is part of a computer network, a workstation, an electronic device, a cell phone, a PDA/handheld computingdevice, a Ultra Mobile PC, a computational device, or the like. Forinstance, a host may be a computing environmental context or setting fora user, such as a context that travels in the communication/computing“ether” with the user.

VM 110, VM 120, and VM 150 may function as self-contained platformsrespectively, running their own “guest operating systems” (i.e.,operating systems illustrated as “Guest OS 111”, “Guest OS 121” and“Guest OS 151” (hosted by their respective VMs 110, 120 and 150) andhereafter referred to collectively or individually as “Guest OS”) andother software (illustrated as “Guest Software 112”, “Guest Software122” and “VEM 280”, and hereafter referred to collectively orindividually as “Guest Software”). Each Guest OS and/or Guest Softwareoperates as if it were running on a dedicated computer. That is, eachGuest OS and/or Guest Software may expect to control various events andhave access to hardware resources on Host 100. The VMM need not justproject a representation of the physical platform or give direct accessto resources. The VMM may also create new virtual devices (e.g. anetwork interface card (“NIC”)) while possibly using Host 100'sprocessor and similar devices (e.g., another NIC) on Host 100 to emulatethose virtual devices. The virtual platform presented to a given VM byVMM 130 may be a hybrid of virtual and physical elements. Therefore,within each VM, the Guest OS and/or Guest Software may behave as if theywere, in effect, running on the virtual platform hardware, supported bythe VMM 130. In reality however, VMM 130 has ultimate control over theevents and hardware resources (which may be physical, such as HostHardware 140, or virtual as created by VMM 130), and allocates resourcesto the VMs according to its own policies. Recursive or layeredvirtualization/VM designs may also be possible, e.g., VM 110 may hostanother virtual host (which may appear to have behaviors like physicalHost 100 or some other virtual host platform, or a hybrid platform.)These types of recursive designs are well known to those of ordinaryskill in the art and further description thereof is omitted herein inorder not to unnecessarily obscure embodiments of the present invention.VMM 130 runs on and accesses hardware Host Hardware 140 (and firmware(BIOS) 103) to accomplish these tasks.

Hardware 140 includes central processing unit (CPU) 101, memory 102, anddata file storage 104. CPU 101 is coupled to basic input/output systems(BIOS) 103. Hardware 140 may represent physical devices that may beinstalled in or on host 100, such as a keyboard, mass storagecontrollers, network interfaces, a mouse, sound cards, etc. BIOS 103 mayrepresent firmware/software instructions that may be stored, forexample, in memory 102 or in a separate, non-volatile memory (as shown).

CPU 101 may be a processor, such as a processor capable of performingthe necessary processing to support VMM 130 and various virtual machinesrunning on VMM 130. CPU 101 may be the central processing units (CPUs)of the host and, thus, control and coordinate the overall operation ofthe environment. In certain cases, CPU 101 may comprise one or morecentral processing units (CPU).

Data file storage 104 may represent a storage memory, mass storagedevice, persistent storage device, physical memory, disk storage, discdrives, flash memory, a secondary storage device (e.g., other than mainmemory or random access memory (RAM)), and/or other data storage devicesor capabilities of computing devices that may be accessed or referencedlocally and/or over a network, wired or wireless medium, and/or theInternet, as known in the art. Moreover, data file storage 104 canrepresent data stored on or at network servers, file servers, Internetservers, and/or client devices that store data in various types ofmemory (e.g., in mass storage devices, such as disk drives, and/or a“storage subsystem” having a number of mass storage devices, such asdisk drives, which may be in a disk array).

Likewise, memory 102 may store instructions and/or data to be operatedon and/or accessed by CPU 101, VMM 130, and/or VEM running on host 100,such as by storing the instructions and/or data at addresses of memory102. Memory 102 may be or include the “main memory” of host 100. Memory102 represents any form of random access memory (RAM), read-only memory(ROM), flash memory, or the like, or a combination of such devices.

To create and manage applications running on the various VMs (e.g., VMenvironments) on a host (e.g., host 100), a user typically has to knowwhich VM the application is running in and manually switch to theappropriate VM. Thus, for example, if the user desires to create andmanage a video game (e.g., Guest Software 112 running on VM 110), theuser has to manually access VM 110, create the application andmanagement information, and launch the game. Thereafter, if the userdesires to create and manage another application (e.g., Guest Software122 running on VM 120), the user has to determine which VM theapplication is running in and manually switch to that VM to create andmanage the application. Although switching between or across VMs may notbe especially cumbersome (e.g., a keystroke sequence to switch from oneVM to another), keeping track of what applications are running on eachVM, how and what configuration of an application has been or is desiredto be created, and how each application has been or is desired to bemanaged, may prove to be difficult, especially if the host is configuredto run more than two VMs (as is likely). For a home PC user, keepingtrack of the various VM environments (e.g., partitions) that are runningon his or her PC and the applications running in each partition mayprove to be highly complex. This complexity is multiplied by keepingtrack of the management of the various VM environments that are runningin each partition. Another multiplication of complexity occurs by tryingto keep track of different VM environments, applications, and managementfor more than one host, such as the different setups for a home PC, alaptop PC, and a work PC. The typical home PC user may not betechnically savvy enough to understand the underlying view of the VMhost and as a result, may have difficulties and/or shy away from fullyutilizing a host, or hosts, running multiple VMs.

According to embodiments, VM descriptors (e.g., descriptors 250) andVEMs (e.g., VEM 280) may be used to provide users with a simplified andenhanced design for provisioning, creating, sharing, and managing VMs(e.g., such as by providing a design for provisioning, creating,sharing, and managing VM environments). For example, FIG. 1 also showsVM 150 including descriptors 250, virtual environment manager (VEM) 280,and guest OS 151. Guest OS 151 may be described as a host OS or as aservice OS, as known in the art. Descriptors 250 may be one or moredescriptors as described herein. Guest OS 151 may be an operatingsystem, such as disk operating system (DOS), Windows® (by MicrosoftCorporation of Redmond, Wash.), UNIX (of Unix System Laboratories®),LINUX® (LINUX® operating system, originally conceived by Linus Torvalds,but now under broad, community-based development by individuals andorganizations worldwide. LINUX® is a registered trademark of LinusTorvalds in the U.S. and other countries. Versions of LINUX® are shippedby Red Hat Corporation of 1801 Varsity Drive, Raleigh, N.C. 27606),OS/2® (by Microsoft Corporation of Redmond, Wash.), OS/9® (by AppleComputer of Cupertino, Calif.), XENIX® (by Microsoft Corporation ofRedmond, Wash.), etc. as known in the art. For instance, OS 151 may bean operating system such as WINDOWS XP®, or another WINDOWS® operatingsystem by Microsoft Corporation of Redmond, Wash. OS 151 may also be aMACINTOSH® operating system by Apple Computer of Cupertino, Calif.

VEM 280 may be a VEM as described herein and may have an instantiationsystem and/or management system. VEM 280 may have access to interfacesto, and/or be able to reference any or all VMs, VMMs, hardware of host100; interfaces to, network connections to, or other accesses to or fromhost 100. For instance, VEM 280 interfaced or linked to VMM 130, such asin a configuration that VEM 280 has interfaces or links between (oracross) VMM 130, VM 110, and VM 120. Interfaces may be implemented insoftware, firmware or hardware. (Firmware and hardware may include PALcode or system management codes and microcode.) VEM 280 may have toassess whether or not VMs exist in a layered virtualization/VMenvironment, and may exist or have interfaces and/or hooks across all VMlayers. Also, if multiple VMMs exist on a host or on multiple hosts, VEM280 may have access to the multiple VMMs. (Multiple VMMs can exist on asingle physical machine if, for example, the hardware resources arepartitioned. Or, for example, multiple VMMs can exist in a layeredvirtualization environment.) Similarly, VEM 280 may have access to otherVEMs located on or at VMM 130, host 100, or other VMMs or hosts linkedto host 100. A link may refer to a network connection, internetconnection, or other link for communicating data between or acrosscomputing entities. VEM 280 may include an instantiation system, such asfor creating VM environments and/or host environments. Likewise, VEM 280may include a management system, such as to implement a managementpolicy to manage other VMs or VM environments. The instantiation systemmay use description information of descriptor 250 to instantiate VMenvironments. Likewise, the management system may use managementinformation of descriptors 250 to manage the VM environments.

VM descriptors (e.g., descriptors 250) and VEMs (e.g., VEM 280) may beused to instantiate or create VM environments (e.g., VMs or VM instancescreated using VM environment descriptors that are modifications orcombinations (e.g., modified versions) of other VM environmentdescriptors for a single user or user authorization), and to manage suchVM environments and their descriptions. Moreover, according toembodiments, VM environment descriptors may provide information that ismore detailed, richer, more flexible, and more manageable than other VMdescription information, other VM management information, and/or otherinformation derived from VMs without a VEM, without a VM environmentdescriptor, and/or without a VM environment. Specifically, these VMenvironment descriptors may allow a VEM to create, aggregate, and manageVM descriptors and VM environments, such as, but not limited to thefollowing (e.g., the following behaviors):

-   -   Resources including:        -   VM resource requirements (e.g., devices, disk, memory,            networking, hardware 140, Internet 505, etc),        -   Software configurations that run in a given VM (e.g., OS,            Applications, guest SW 112, guest OS 111),        -   Other such resources (e.g., resources of another host,            etc.).    -   Data including:        -   File systems (e.g. user data files, OS and software            application files, etc), user customizations, and other VM            environment-specific data (Can be encrypted for security),        -   Other such data.    -   Security and Identity including:        -   User identity, permissions and access control lists,        -   Encryption keys/protocols,        -   Other external world protections (e.g. allowed network            access and firewall restrictions),        -   Single [user] sign-on authentication,        -   Other such security and identity.    -   Management Policies including:        -   Local (e.g. personal, family, work group, etc) or Global            (e.g. corporate),        -   Other such management policies.    -   Log files including:        -   Usage histories and logs        -   Other such log files.

Thus, a specific VM environment may be similar to, copied from, amodified version of, and/or created using or including information froma VM environment descriptor for another VM environment or instantiation,except the specific VM environment has a constrained facet and/orextended facet on any of the above behaviors. Similarly, a specific VMenvironment may have more than one constrained facet and/or extendedfacet on any of the above behaviors, as compared to another VMenvironment or instantiation (e.g., according to the modified version ofthe descriptor as compared to another VM environment or instantiation).For some specific examples of such descriptors and VM environments seeFIG. 4. In some cases, a VEM may be described as a module that includesa virtual machine environment management and policy module. Also, a VMenvironment may describe a virtual machine, an instantiation of avirtual machine according to a VM environment descriptor, or aninstantiation of a virtual machine that may or may not have constrainedfacets and/or extended facets as compared to an instantiation of anothervirtual machine. A behavior may include an ability, access, function, orother characteristic related to resources, data, security and identity(e.g., user identities, such as to allow for sign-on access to a VEM),permissions, applications, log files, and/or management thereof. Forexample, a constrained facet of a behavior may include management,restriction, limitation, denial, exclusion, or constraint of a behavior(e.g., of an ability, access, function, or other characteristic relatedto resources, data, security and identity, permissions, applications,and/or management thereof). On the other hand, an extended facet of abehavior may include management, addition, extension, increase,inclusion, or incorporation of a behavior (e.g., of an ability, access,function, or other characteristic related to resources, data, securityand identity, permissions, applications, and/or management thereof).Such constrained facets and/or extended facets may be the result ofusing a modified version of or as compared to the descriptor of aninstantiation of another virtual machine.

For example, a VEM may create virtual machine environments according todescriptors and using data files associated with the descriptors. TheVEM may create the virtual machine environments by sending,distributing, and/or designating descriptor information and data filesassociated with the descriptor information (e.g., a “set” of one or moredata files and metadata to be used and/or modified by the VMM and/or VMenvironment during creation, execution, and/or management of a VMenvironment) to a virtual machine monitor (VMM), which creates the VMenvironment according to the descriptor. Moreover, the VEM may manage VMenvironments executed by the VMM, according to the descriptors. The VEMmay reference descriptors such as by combining descriptor informationfrom one or more descriptors to create another descriptor. The VEM mayalso access data files according to descriptor information, such as byaccessing binaries, software applications, audio data, video data, textdata, blocks of data, graphics data, or other data from a persistentstorage device, storage memory, or accessed otherwise. Moreover,descriptor information and/or descriptors may be imported from similarlyto the access of data files described above.

According to embodiments, a VEM may be accessed using a unified, singlesign-on authentication, such as to allow a user to use a unificationconsole to access a VEM and to specify or select separate hostenvironment management policies for a VM, a user, a host, a home desktopcomputer, a laptop computer, and/or a work computer. Thus, anenvironment having such an enhanced design of one or more VEM modulesand such sign-on access to the VEM(s) may be described as a “logicallyunified and/or monolithic”. Similarly, a compute environment including acollection of one or more VM descriptors, VM instantiations, and/or useridentities (e.g., according to or selected at one or more VEM modulesaccessed by users according to the user identities) may be described asa “logically unified (monolithic) compute environment”.

Moreover, it is considered that “collecting” (e.g., such as by a userusing a VEM and/or a unification console) and/or a “collection” of oneor more user identities, VM descriptions, VM instantiations, hosts, VMenvironments, and/or VMMs may include one or more user identities, VMdescriptions, VM instantiations, hosts, VM environments, and/or VMMsrelated or associated by having or being accessible by one or morecommon, same, equal, or similar user identities, VM descriptions, VMinstantiations, hosts, VM environments, and/or VMMs. In some cases,“collecting” (e.g., such as by a user using a VEM and/or a unificationconsole) and/or a “collection” of one or more user identities, VMdescriptions, VM instantiations, hosts, VM environments, and/or VMMs mayinclude a collection of one or more VM environments for a single user,group of users, single user authorization, and/or group of usersauthorization. Related or associated may be described as applying tosimilar or the same one or more users, groups of users, families(immediate or extended) of users, user authorizations, group of usersauthorizations, VEMs, VMMs, hosts, home desktop computers, laptopcomputers, work computers, company computers, and/or the like.

Also, according to embodiments, the logically unified computeenvironment may be created across one or more hosts (e.g., theenvironment may exist on only on host, or on or across numerous hosts).Similarly, the logically unified compute environment may be createdacross a collection of one or more user identities (e.g., identitiesthat are related or are not related). For example, the logically unifiedcompute environment may be created or apply only to one user with one ormany different logins; many users, each with one or several logins;and/or one or more users, each with several logins where each loginprovides/accesses different privileges (e.g., different constrainedfacets and/or extended facets). Next, the logically unified computeenvironment may be created across one or more VMMs, such as where eachVEM manages one or more, possibly disparate VM environments runningunder different VMMs (e.g., which may or may not include the managingVEM).

It is also contemplated that the unified compute environment may includea collection of VM descriptors and/or instantiations may be distributedacross one or more hosts. Likewise, the unified compute environment mayinclude a collection of VM descriptors and/or instantiations designatedacross one or more hosts. Designation or assignment of VM descriptorsand/or instantiations to specific hosts permits control over a varietyof practical matters including, but not limited to, cost, availability,reliability, scaling, resource use and load balancing, host security,and so on.

Using VM environment descriptors, embodiments of the present inventionprovide users with improved VM creation and management designs orsystems that enhances the usability of virtual machines. Morespecifically, embodiments of the present invention improve creation ofVM environments and host environments in a virtualized environment, suchas to allow a user to create a separate host environment (e.g., acollection of one or more VM environments for a single user, group ofusers, single user authorization, and/or group of users authorization)for a home desktop computer, a laptop computer, and a work computer froma VEM (e.g., from a single VEM). In an embodiment the VEM facilitatesaggregation of this collection. The VM or host embodiments can becreated using an instantiation system of a VEM (e.g., see VEMinstantiation system 380 of FIG. 3). The instantiation system may be aportion of a VEM. The user may select description information (e.g.,description information that is part of the descriptor and describes a“VM configuration” for creating a VM environment) describing each VMenvironment, its behavior and/or constrained facets and/or extendedfacets on its behavior. This information may be a detailed descriptionof a configuration for each VM that includes a description of behaviors,resources (e.g., access to a hardware resource), data, security andidentity (e.g., a user sign on authentication for access and/or a userpermission for use), functions, permissions (e.g., a read datapermission and/or a write data permission), applications (e.g.,functionality of a software application), constraints on facets ofbehaviors (e.g., constraints described by the description informationfor creating this VM environment as compared to a descriptor of anotherVM environment), etc., for each VM environment of each host environment,and create a descriptor for each VM environment. A VEM at each host mayuse the descriptors to create or instantiate the appropriate VMenvironments for each host environment according to the descriptioninformation selected by the user for each descriptor. Thus, the VMM ofeach host may run each VM environments differently or the same on eachhost, as desired by the user.

Moreover, such creation may be automated, such as where after selectionof the description information, the VEM creates the VM environmentswithout user selection of data files associated with the descriptioninformation. For example, without further user interaction, the VEMaccesses, obtains, reads, or acquires the appropriate data files to beused to create the VM environment according to the user selection ofdescription information.

Similarly, embodiments of the present invention improve management ofthe VM environments and host environments in a virtualized environment,such as by allowing a user to specify or select separate hostenvironment management policies (e.g., management information that ispart of a descriptor and describes a “VM management policy” for managinga VM environment) for a user (e.g., for a single user, group of users,single user authorization, and/or group of users authorization), a host,a home desktop computer, a laptop computer, and a work computer.Selection of those management policies and/or management according tothose policies may be done at or from one or more VEMs (e.g., from asingle VEM). The VM or host embodiments can be managed using amanagement system of a VEM (e.g., see VEM management systems 684 and 686of FIGS. 6A and 6B). The management system may be a portion of a VEM,and may or may not include an instantiation system. This information maybe included in a detailed description of a management policy for eachVM.

In some cases, a management policy may include a personal managementpolicy, a family management policy, a work management policy, a desktopcomputer management policy, a laptop computer management policy, and acorporate management policy, etc. Moreover, these management policiesmay be related or associated, such as where a policy applies to VMs forone or more users, groups of users, families (immediate or extended) ofusers, user authorizations, group of users authorizations, VEMs, VMMs,hosts, home desktop computers, laptop computers, work computers, companycomputers, and/or the like.

For example, the user may select management information describingsecurity and identity, management policies, log files, constraints onfacets of (e.g., a constraints on behaviors of an executed VMenvironment, according the management information of a descriptor forthat VM environment). The management information may also describeexclusions to, and/or restrictions, and/or enhancements, and/orextensions to VM behaviors, resources (e.g., access to a hardwareresource), data, security and identity (e.g., a user sign onauthentication for access and/or a user permission for use), functions,permissions (e.g., a read data permission and/or a write datapermission), applications (e.g., functionality of a softwareapplication), etc., for each VM environment of each host environment,and include that information in a descriptor for each VM environment.Facets that are not the same or equal, but are not constrained eithermay be described as extended facets or enhanced facets. In some sense,these facets may be described as un-constrained facets because they maybe facets that add an “extension” or “enhancement” to a givenconfiguration (e.g., according to an “extension” or “enhancement” to agiven descriptor). Thus, an enhanced and/or extended facet could enhanceand/or extend (e.g., but not just constrain) VM behaviors by adding somenew capability/permission/etc.

A VEM at each host may use the descriptors to manage VM environmentsrunning or executed on each host environment according to the managementinformation selected by the user for each descriptor. Such managementmay include automating the constraints or enhancements on facets ofbehaviors, stopping, denial, classification, replication, filteringand/or transforming of data and/or data requests entering and leavingthese VM environments.

Moreover, such management may be automated, such as where afterselection of the management information, the VEM manages the VMenvironments without user selection of management policies. For example,without further user interaction, the VEM manages by causing stopping,denying, classification, replication, filtering and/or transforming ofdata and/or data requests entering and leaving these VM environments(e.g., See FIGS. 6A and 6B).

Thus, (e.g., with respect to creation of VM environments) a constraint(e.g., a constrained facet and/or extended facet) of a behavior maydescribe a restriction of, extension of, or difference (e.g., accordingto a modified version of a descriptor) between access to a hardwareresource, functionality of a software application, a read datapermission, a write data permission, a user sign on authentication foraccess, a user permission for use, and/or a management policy of thesecond VM environment as compared to a first VM environment. Inaddition, (e.g., with respect to management of VM environments) aconstraint of a behavior may describe a restriction (e.g., according tomanagement information of a descriptor) of one of access to a hardwareresource, functionality of a software application, a read datapermission, a write data permission, a user sign on authentication foraccess, and/or a user permission for use of a VM environment, etc.

In some cases, the VEM module (e.g., a VEM) may be described as“long-lived”, such as by being present, existing, or being executedwhenever a VMM of a host is present, existing, or being executed. Insome cases, the VEM module may be hosted in a “true” virtual machine(e.g., FIG. 1). Alternatively, in some embodiments, a VEM module may bedescribed as part of the “host” software (e.g. hosting OS, if any, suchas VM workstation product) and VMM.

For example, FIG. 2 illustrates a host computing device having a VEM aspart of a VMM. FIG. 2 shows host 200 including VEM 290 interfacing orlinking enhanced VMM 230, descriptors 250, VM 110, and VM 120. VEM 290may provide the same functionality as VEM 280 (FIG. 1). Moreover, it maybe transparent to the user whether or not the user is interacting withVEM 280 or VEM 290. Enhanced VMM 230 may provide all the functionalityof VMM 130. In some cases, enhanced VMM 230 may be described as enhancedby including VEM 290 and/or descriptors 250.

According to some embodiments, a VEM may be described as or include avirtual (machine) environment instantiation or creation system toinstantiate or create VMs, VM environments, and/or VM instances, such asaccording to description information contained in a descriptor.Similarly, a VEM may be described as or include a virtual (machine)environment management system to manage VMs, VM environments, and/or VMinstances, such as according to management information contained in adescriptor and/or according to a management policy.

For example, FIG. 3 illustrates creation of VM environments. FIG. 3includes VEM 380 having VEM instantiation system 382 having referenceto, accessing, interfacing to, and/or linked to descriptors 250, datafile storage 104, and VMM 330, such as through VEM 380 or interfacesthereof. Similarly, VMM 330 is interfaced with or linked to VMenvironment 310 and VM environment 320. VEM 380 may be a VEM asdescribed above with respect to VEM 280 or VEM 290. VEM instantiationsystem 382 may be a system of a VEM, or a portion of VEM 380. Likewise,VMM 330 may be a VMM as described above with respect to VMM 130 or VMM230.

VM environment 310 may be a VM, a VM environment, or a VM instance asdescribed herein. For example, VM environment 310 may be a VM created byVEM referencing description information and/or management informationfrom one or more descriptors of descriptors 250 and accessing one ormore data files stored in data file storage 104 according to thedescription information, and sending (or distributing) the descriptioninformation and/or management information and data files to VMM 330. Inturn, VMM 330 may create, or instantiate VM environment 310 according tothe descriptor information. Likewise, VMM 330 may execute VM environment310. Moreover, VEM 380 may manage VM environment 310 according to themanagement information (management interface or link not shown in FIG. 3but shown in FIGS. 6A and 6B, such as management systems 684 and 686).VM environment 320 may be a VM environment similar to, created similarto, and/or managed similar to environment 310. Environments 310 and 320may exist on the same or on separate hosts or VMMs. Similarly,environments 310 and 320 may be managed by the same or different VEMs.In a situation where environments 310 and 320 exist on a single host,they may describe a “host environment.” For example, referring to FIG.2, if environment 310 represents VM 110 and environment 320 representsVM 120, those VMs describe the host environment of host 200 (e.g., suchas a host environment where no other VM environments are running orbeing executed).

A VEM descriptor (e.g., descriptor 250) may provide a description of howto construct a similar environment, but may lack specific files orbinaries. For instance, a descriptor may include descriptioninformation: a VM with 250 GB of HDD, 1 GB of memory, network with only3 ports open, running Linux, and the “Elm” mail application. It couldalso include additional properties of the VM such as security policies(e.g., management information). The VEM descriptor may also include metadata relating to specific applications contained within a VM (e.g.,description information). For example, it could include details aboutconfiguration data for the Elm e-mail application and windows mediaplayer (e.g., description information). However, it should be noted thatthe VEM descriptor may contain only meta data and not applicationbinaries or data files.

In some cases, a descriptor may include a single or only one “piece” ofinformation of a description or management information. A “piece” ofinformation may be described an “an information” or “one information”.For instance, a descriptor may only describe a software application, amemory address, a password, etc. Alternatively, a descriptor may includemore than one information of description and/or management information.For instance, a descriptor may include more than one information of onlydescription or management information. Alternatively, a descriptor mayinclude more than one information of description information and ofmanagement information.

In addition, and accordingly, a VM environment may include the image ofa virtual machine and its constituent elements (processor state, memoryand disk images (files, binaries), etc). (A descriptor can always bederived from a VM environment through appropriate abstraction.) Forexample, one VM environment might be for Susan's personal video recorder(PVR) VM. In addition to the VM environment hosting the PVR, other VMmanagement information might be associated with the instance includinggiving a user (e.g., Susan) read (R)/write (W) permissions, Susan'sfamily R-only permissions as well as various network restrictions (suchas permitted schedule update site, local IP addresses only and IP-basedremote control).

The VEM module permits hybrid VM instantiation (e.g., to create VMenvironment which may be a VM instantiation according to a combinationof a VM environment descriptor) to be constructed in which only selectelements are included (e.g. a specific set of files, but not all files,such as a single document or document set.) It may allow fordecomposition of the VM itself (into constituent applications etc) suchthat a VEM module can create VM environments which may includeconstraining facets on the behavior of the original VM. For example, aVEM can create a VM environment of the E-mail VM (a VM which isprimarily dedicated to running the users e-mail application) whileconstraining the downloading of e-mail from the server, mandating thatthis incantation (e.g., VM environment) of the e-mail VM must leavee-mail on the server. This may be particularly useful when this VMenvironment is being created or instantiated for example on a publiclyaccessible host or computer. By disallowing the downloading of e-mailinto this VM environment, the user may not inadvertently leave anye-mail on the public host.

The VEM module also permits sets or collections of VM environmentdescriptors and/or VM environments to be collected. The most commoncollections include sets of descriptors and/or VM environments whichhave a single security/identity/management policy (e.g., a collection ofone or more VM environments for a single user, group of users, singleuser authorization, and/or group of users authorization).

For example, at user login the VEM module can be used locate a desiredVM or host environment and to authenticate to that environment. Numerouspossible VMs (with a limited set of applications) might coexist as partof a user's “environment” (e.g., for a single user or single userauthorization). These might include virtual partitions for gaming,personal video recorder, information technology (IT)/telecommutepartition, digital jukebox for music/movies, e-mail and instantmessaging (IM), web browsing, picture/video editing, Voice over InternetProtocol (VoIP), home automation, finances/banking/investment control,legal, location manager, personal information manager (PIM) functions,travel, test partition for new applications, legacy software, etc. TheVEM module helps describe, instantiate, manage, and share such anenvironment.

For instance, FIG. 4 illustrates a default host environment and a travelhost environment for a user. FIG. 4 shows environment 400 includingshowing VM environment descriptors and a VM environment in each hostenvironment for a default host environment and a travel host environmentfor user Sally Carr. Environment 400 includes Sally Carr's defaultenvironment 410 and Sally Carr's travel environment 460. Defaultenvironment 410 includes VM descriptors 412, 414, 416, 418, 420, 422,424, 426 and 428. Travel environment 460 includes VM descriptors 462,464, 470, 474 and 478. As shown in FIG. 4, descriptor 462 is a modifiedversion of descriptor 412, such as a copy of descriptor 412, butincluding more, less, and/or different description and/or managementinformation than descriptor 412. In the default environment 410, the VEMwill make sure that a VM matching descriptor 414 is instantiated as itis always resident and running. Other VMs may be instantiated orsuspended or created or destroyed as needed. These VMs are described bythese descriptors.

Thus, descriptor 462 may be used to create and manage a VM environmenton travel host environment 460 that disallows the downloading of e-mailinto this travel host VM environment, so the user may not inadvertentlyleave any e-mail on the travel host (e.g., in case this host isaccessed, lost, or stolen at a public or non-secure location). Amodified version of a descriptor may include all or a part of anotherdescriptor sent or imported from another host, user, vendor, etc. Also,a modified version of a descriptor may include a copy of anotherdescriptor, made when a user wants to clone aspects of anotherconfiguration as a “frame” (e.g., a copied frame descriptor) and thenfill in other details (e.g., other information added to the framedescriptor to create the modified descriptor). This might particularlybe true if, in the modified version, the user wants to add or removefrom the original VM environment (e.g., the VM environment created andmanaged according to the frame descriptor) special limitations/limitersput in place (e.g., disallows the downloading of e-mail as noted above,protections or resources allocations such as shown in descriptors ofFIG. 4, and/or access denial of FIGS. 6A and 6B). Thus a modifiedversion may provide variations within the confines of a “frame” orskeletal set of capabilities/configuration (e.g., of a framedescriptor). According to embodiments, an approach would be variationsof the frames themselves. In some cases, a user might change fundamentalelements (e.g. number of processors described in a descriptor forcreating a VM). Other examples of modified versions of VM environmentdescriptors are contemplated, such as to subsequently alter any of thetypes of description and/or management information, including the typesof information shown in FIG. 4.

Similarly, VMM descriptor 464 may be used to instantiate or create a VMaccording that has more, less, or different description informationand/or management information than the descriptor 414, which is used toinstantiate, create and/or manage a PVR VM. For example, descriptors 414and 464 may be for a personal video recorder (PVR), wherein travelenvironment 460, a portable PVR is configured as a subset or modifiedversion of default environment 410's PVR (such as where environment 414is a home or resident PVR). Thus, environments created from descriptors414 and 464, respectively, can share programming/content over a network,or the Internet, if needed. Moreover, in such an example, it is possiblethat only the home PVR has a television (TV) tuner available.

Descriptor 470 may be an exact copy of descriptor 420, such as by havingthe same amount and same description information and managementinformation as descriptor 420. Likewise, descriptor 474 may be an exactcopy of descriptor 424; and descriptor 478 may be an exact copy ofdescriptor 428. Travel environment 460 does not include a descriptorderived from, corresponding to, or including information from descriptor422 or 426.

VEM modules also can communicate with other VEM modules on otherphysical hosts. The VEM can be used by a single user with one or moremachines as well as between or across different users or groups ofusers. For instance, FIG. 5 illustrates VM environments and hostenvironments running on hosts. FIG. 5 shows host 500 (Sally/Jim's homePC) including VMs 510, 520, 522, 524, and VEM 580 running on VMM 530.Host 500 includes VEM 580 as a VM or a VM environment. These VMs aremerely illustrative, as host 500 may include more or fewer VMs (e.g.,see description above with respect to FIG. 1). In addition, any of VMs510, 520, 522, or 524 may be a VM as described above with respect to VM110. Similarly, VMM 530 may be a VMM as described above for VMM 130 ofFIG. 1.

FIG. 5 also shows VEM 580 including various behavior modules, such asresource management 582, access control list (ACLs) management 584,interface management 586, and VEM interfaces (I/F's) 588 and host OS551. These behavior modules are merely illustrative, as VEM 580 mayinclude more or fewer behavior modules to perform behaviors as describedherein (e.g., see description below). For instance, host 500 includesVEM 580 interfacing or linking VMM 530, resource management 582, ACLsmanagement 584, interface management 586, VMs 510, 520, 522, and 524.More particularly, VEM 580 includes VEM I/F's 588 interfacing or linkingVMs 510, 520, 522, and 524 to VMM 530.

VEM 580 references or otherwise accesses descriptors 550, which aredescriptors at host 500. Descriptors 550 may include descriptors, suchas descriptors 250, or descriptors as otherwise described herein. VEM580 is running in a VM on VMM 530 and/or as a VM on host 500 (e.g., seeFIG. 1). VEM 580 may be a VEM as described above with respect to VEM 280of FIG. 1. Similarly, OS 551 may be an OS such as guest OS 151 of FIG.1.

FIG. 5 also shows host 502 (Sally's work PC) including VMs 512, 514,516, and 518 running on VMM 532. These VMs are illustrative and may beas described above with respect to VM 510 of host 500. VMM 532 may be anenhanced VM as described above with respect to enhanced VMM 230 of FIG.2. Host 502 includes VEM 590 as part of VMM 532.

Specifically, FIG. 5 also shows VEM 590 including various behaviormodules, such as resource management 592, access control list (ACLs)management 594, interface management 596, and VEM interfaces (I/F's)598. These behavior modules are merely illustrative, as VEM 590 mayinclude more or less behavior modules to perform behaviors as describedherein (e.g., see description below). For instance, host 502 includesVEM 590 interfacing or linking VMM 532, resource management 592, ACLsmanagement 594, interface management 596, VM 512, VM 514, VM 516, and VM518. More particularly, VEM 590 includes VEM I/F's 598 interfacing orlinking VMs 512, 514, 516, and 518 to VMM 532.

VEM 590 references or otherwise accesses descriptors 552, such asdescriptors at host 502. Descriptors 552 may include descriptors, suchas descriptors 250, or descriptors as otherwise described herein. VEM590 is running as part of VMM 532 on host 502 (e.g., see FIG. 2). VEM590 may be a VEM as described above with respect to VEM 290 of FIG. 2.VEM 590 is shown having resource management 592, ACLs management 594,and interface management 596.

FIG. 5 shows internet 505 interfacing or linking host 500, client 510and host 502. Note that although host 502 is shown as hosted on client510, host 500 and/or 502 may be hosted on various computing devices asdescribed with respect to host 100 of FIG. 1.

Thus, embodiments of the invention allow for management (e.g., creationof VM environments and/or management of VM environments) on host 500 and502 from either or both host 500 and 502. For example, FIG. 5 shows VM516, Sally's IT-compliant work partition that may be created on, sentto, or managed on host 502. However, the descriptor and VEM that createdVM 516 may be on either host 500 or host 502. For example, the ITdepartment that administers Sally's work PC may create the descriptorfor VM 516 at host 502. The IT department can make the descriptor for VM516 available to Sally. Sally can then send or distribute the descriptorthrough a network (e.g., internet 505), on a disk, on a portable memorydevice, etc., to host 500. Upon receiving the descriptor (e.g.,referencing the descriptor) VEM 580 accesses the data files described inthe descriptor and sends the descriptor and data files to VMM 530 whichcreates an Sally's Work IT-compliant VM environment “clone” of VM 516according to the descriptor, call it VM 516 h (not shown), but this VMis on Sally's/Jim's Home PC. Permissions are established so that onlySally can access this new VM. VMM 530 then executes VM environment 516 hon host 500, and may manage VM environment 516 h according to thedescriptor received from host 502.

Also, according to embodiments, the VEM can perform various behaviors,including creating, monitoring, communicating, managing, updating,transmitting, importing, sending, distributing, abstracting,authenticating, and other tasks with (e.g., to, for, associated with,according to, between, across, or over) VM environment descriptors andVM environments, such as, but not limited to the following (e.g., thefollowing behaviors):

-   -   Ability to create, destroy, copy, modify, VM environment        descriptors (e.g., descriptors shown in FIGS. 2, 4, and 5) and        VM environments (e.g., VM environments shown in FIGS. 1-6),        including associated attributes and/or metadata (e.g.,        attributes and/or metadata of descriptors and VM environments as        shown in FIG. 4).    -   Ability to create, destroy, copy, modify, sets of VM environment        descriptors and/or sets of VM environments, including associated        attributes/metadata (e.g., such as a set of or for a host).    -   Ability to send, distribute, and/or designate VM environment        descriptors, VM environments, and sets of VM environment        descriptors/VM environments to other VEMs including (e.g., such        as sending or importing from host 500 to host 502 or vice        versa).        -   E.g. Send Charlie my Project X VM,        -   E.g. Send John my PVR environment, but not the video            content,        -   Sending other such VM environment descriptors, VM            environments.    -   Ability to encrypt/decrypt VM environment descriptors, VM        environments, and sets of VM environment descriptors/VM        environments (e.g., using encryption keys and/or protocols for        security reasons).    -   Ability to create hard/soft links to VM environment descriptors,        VM environments, and sets of VM environment descriptors/VM        environments (e.g., a hard link directly references the desired        object, a soft link typically specifies a path that requires        further resolution (e.g. /users/home/rob/.pvr.vem) such as “get        from Rob's home directory” to provide access to a software        application). In an embodiment some links to descriptors have        copy-on-modify behavior (e.g. a separate, local copy of a        descriptor is made if an attempt is made to modify it.); the        original descriptor copy remains unchanged. Whereas in other        kinds of links, the original descriptor copy is changed by any        modification.    -   Ability to register for change updates from a particular VEM's        information (e.g., such as by subscribing to a source of data        from another VM), including:        -   E.g. update my IT-compliant VM with changes from IT's            reference VM,        -   E.g. update my Project X VM with changes from Charlie's            Project X VM,        -   E.g. update my Project X VM with permissions/ACL updates by            the project lead,        -   Other such registrations or subscriptions.    -   Ability to create or instantiate a VM environment from a VM        environment description (e.g., see FIGS. 3 and 7).    -   Ability to abstract a VM environment descriptor from a VM        environment (e.g., a descriptor can be derived from a VM        environment, such as through appropriate abstraction of        applications and data files of the VM environment).    -   Ability to create VM environments or VM environment descriptions        from most recently used VM environments, data files, and/or        applications (e.g., a user intends to travel and wants to only        take work and computing context from recent activity. This        permits the user to automatically identify and “bundle” up the        compute environment and data files required to continue work        remotely.)    -   Ability to substitute compatible elements and perform required        translations (or best effort) (e.g., translations of description        and/or management information of descriptors for creating and/or        management of VM environments on different OSs) including:        -   E.g. Moving information to systems that cannot instantiate            certain OS or applications, but have other known            substitutes,        -   translating information of one descriptor into information            of another descriptor that can created, executed, and/or            managed a one VM environment on an operating system that is            unable to created, executed, and/or manage the another VM            environment according to the one descriptor,        -   Other such substitutions and/or translations.    -   Register and receive automatic updates for a given VM        environment. (e.g. files, permission changes, etc., such as by        subscribing to a source of data from another VM) (e.g., in order        to update a VM environment according to a change to another VM        environment)    -   Ability to import and/or designate VM environment descriptors        and VM environments and make appropriate permissions/ACL        changes.    -   Single sign-on authentication of users to a VM environment or        set of VM environments that may be a host environment or a        user's environment.    -   Ability to aggregate and respond to management requests for one        or more VM's (e.g., where one VEM manages VM behavior according        to a request from another VEM on the same or a different host).

Thus, a specific VM environment may be similar to, copied from, createdusing or include information from a VM environment descriptor foranother VM environment or instantiation, except the specific VMenvironment has a constrained or extended facet on any of the abovebehaviors. Similarly, a specific VM environment may have more than oneconstrained facet and/or extended facet on any of the above behaviors,as compared to another VM environment or instantiation.

Moreover, VEM 580 may include an instantiation system and a managementsystem. Likewise, VEM 590 may include an instantiation system and amanagement system. For example, FIG. 6A illustrates VEM denial of accessto a resource for a VEM as a VM. In one embodiment the denial of serviceis implicitly made through configuration of the VM and VMM as per the VMenvironment descriptor; that is, the VMM enforces the resource use.However, in an embodiment, the VEM can also play a more active role.FIG. 6A shows host 600 including VEM management system 684 as part ofVEM 580, network interface card (NIC) VM 610, and NIC hardware (HW) 642(as part of hardware 140). Host 600 may be a host as described abovewith respect to host 500, except that host 600 shows VEM managementsystem 684, includes NIC VM 610 instead of VM 510 and must include NIChardware 642.

FIG. 6A shows VEM 580 denying or stopping VM access request 620 to NICHW 642 from reaching NIC HW 642. Specifically, request 620 istransferred to VEM I/F's 588 along choke point 622. As noted, such chokepoints may be points through which all input/output (I/O) to and from aVEM and a VM or a VMM typically traverse. Thus, the choke points may beused by VEMs to perform behaviors, managing, monitoring and/or filteringof data, data communications, access, behavior, etc. Specifically, forinstance, upon receiving request 620, VEM management system 684, denies,stops, or otherwise refuses request 620 to be sent to NIC HW 642, suchas according to management information in a descriptor used to createand/or manage NIC VM 610. Specifically, FIG. 6A shows denied accessrequest 626 where request 620 would have been sent, had it been allowedto cross choke point 624. However, instead, request 620 is stopped atpoint 628 by VEM management system 684.

FIG. 6B illustrates VEM denial of access to a resource for a VEM as partof a VMM. FIG. 6B shows host 602 including VEM management system 686 ofVEM 590, NIC VM 610, and NIC HW 642. Similar to the description abovewith respect to FIG. 6A, host 602 may be similar to host 502, except forhost 602 shows VEM management system 686, includes NIC VM 610 instead ofVM 512, and includes NIC HW 642 as part of HW 140.

Similarly, FIG. 6B shows VEM management system 686 denying VM accessrequest 630 of NIC VM 610 from reaching NIC HW 642. Although request 630transacts through choke point 632, to VEM I/F's 598, it is stopped atpoint 638, and not allowed to pass through NIC HW 642, as shown bydenied access request 636. Note that in the case of VEM managementsystem 686, it is not necessary that a choke point exist betweeninterfaces 598 and VMM 532 as VEM 590 (and hence VEM management system686) is part of VMM 532.

Moreover, according to embodiments, some or all of the management system(e.g., management of a VM environment, such as controlled by a VEM andaccording to management information of a descriptor) could run in anapplication or device driver on the Host OS, be part of the host OSitself, and/or be run in a separate (distinguished/special) VM. Forexample, FIG. 6A shows Host OS 551, such as a “service OS”, on which VEMmanagement system 684 is running.

For instance, a service OS may be a host OS that permits the managementsystem to run and request actions of the Host OS for controlling theplatform to permit access or not to various resources, etc. (e.g., seedenial of NIC HW access above). In some cases, a service OS (e.g., OS551) also makes it possible for any management components (e.g., adriver, and/or a component of management system 684 and/or VEM 580)running in the Host OS environment to “talk” to the other elements ofthe management system interface (e.g., I/F's 588) or of the VMM (e.g.,VMM 530).

In some cases, the VEM Management system 684 may “trampoline” throughthe VMM 530 to talk to the management system interfaces (VEM I/F's 588).For instance this might be required if VEM I/F's 588 was integrated aspart of VMM 532, but other VEM 684 management functionality were hostedby the OS 551. In other cases, for example, the VEM Management system686 may talk to it directly) to VEM I/F's 598. For instance, FIG. 6Bshows an implementation where management system interface, I/F's 598 arepart of VMM 532. Here, the VEM Management system 686 which is also partof VMM 532 may talk directly to I/F's 598, such as to manage VMenvironments of host 602.

FIG. 7 is a flow chart that conceptually illustrates an example ofcreation and management of VM environments. FIG. 7 shows process 700,which may or may not be a process for creating, running, executing,resuming, and/or managing VM environments, such as for a VM host, asdescribed above with respect to FIGS. 1-6.

Creating a VM environment may describe where FIG. 7 refers to executingan environment not executed by the host since the current OS boot up.Resuming a VM environment may describe where FIG. 7 refers to executingan environment that has been previously executed by the host since thecurrent OS boot up. Thus, to start up (e.g., execute) a VM that hasalready been created before, a VM can be executed (resumed) according tothe information for a descriptor for the previously created VM (e.g., adescriptor having updated information describing the executed VM).

Process 700 includes block 710 at which a VEM references a descriptor.For instance, referring to FIG. 5, a descriptor from either host 500 and502 may be referenced. Also, in some embodiments such a descriptor maybe created by referencing multiple descriptors either or both host 500and 502. Specifically, the descriptor above for Sally's IT-compliantwork partition, VM 516, may be referenced by VEM 580 of host 500 from adescriptor at VEM 590 of host 502 to create a VM environment at host 500based on or similar to VM 516 (e.g., so Sally can do some work at homeon the home PC). This referencing may be described as importing thedescriptor, such as where the descriptor (or information for creatingthe descriptor to be referenced by VEM 580) is “pulled” or accessed byor to host 500 (e.g., VEM 580) from host 502 (e.g., VEM 590 ordescriptors at VEM 590). Alternatively, this referencing may bedescribed as sending the descriptor, such as where the descriptor (orinformation for creating the descriptor to be referenced by VEM 580) is“pushed” or transmitted to host 500 (e.g., VEM 580) from or by host 502(e.g., VEM 590 or descriptors at VEM 590). Note that the descriptionsabove for block 710 describe a descriptor pushed or pulled to host 500,which is different than the description above for FIG. 5, where a user(Sally) creates the descriptor for VM 516 at host 500, and then sends orpushes the descriptor through a network to host 502.

At block 720, upon or after referencing the descriptor, a VEM accessesthe data files described in, corresponding to, or identified by thedescriptor. In some cases, the VEM in blocks 710 and 720 is the sameVEM, or is a VEM on the same host. For instance, referring to FIG. 5,VEM 580 may reference a descriptor and accesses the data filescorresponding to that descriptor for creating VM 516. The descriptor mayhave description information for creating one or more VM environmentsand/or management information for managing one or more VM environments.

At block 730, upon or after accessing the data files, a VEM sends orprovides the descriptor (or translated actions dictated by thedescriptor) and the corresponding data files to a VMM. It is alsoconsidered that at block 730, upon or after accessing the data files, aVEM sends or provides substituted and/or translated actions dictated bythe descriptor and the corresponding data files to a VMM. Thesubstituted and/or translated actions may be sent in cases where the VMMmay not be capable of understanding the descriptor (e.g., because thatVMM is not able to instantiate an OS or application required for anaction of the descriptor). In this case, the VEM may automaticallysubstitute a translated action dictated by the descriptor to the VMM,the translated action for an OS or application an action of thedescriptor that the VMM is not able to instantiate. Therefore, the VEMmay need to send commands, etc. to the VMM in the VMM's own parlance tocarry out what the descriptor describes.

In some cases, the VEM in blocks 710, 720 and/or 730 may be the same ordifferent VEMs, or VEMs on the same or different host. Likewise, in somecases, the VMM in block 730 may be on the same or a different host thanthe VEM of blocks 710, 720 and/or 730. For instance, referring to FIG.5, VEM 580 may send the descriptor (or actions directing the VMM) andcorresponding data files to VMM 530 or VMM 532 to create VM 516according to the descriptor.

At block 740, upon or after receiving a descriptor (ordescriptor-derived actions) and the corresponding data files, a VMMcreates a VM environment according to the descriptor, such as using thedata files associated with the descriptor. In some cases, the VMM inblocks 730 and 740 is the same VMM, or is a VMM on the same host. Forinstance, referring to FIG. 5, VMM 530 and/or VMM 532 may create VM 516according to the descriptor and using the data files associated with thedescriptor. According to embodiments, if VMM 530 creates VM 516 on host502, then VMM 530 creates VM 516 on host 500 (e.g., VM 516 h asdescribed). Alternatively, in some cases, if VMM 532 creates VM 516 onhost 502, then VMM 532 creates VM 516 on host 500. In some cases,instead of instantiating a new VM, the VMM will simply locate andrestore a suspended VM meeting the descriptor criteria.

At block 750, upon or after creating a VM environment, the VMM executesthe VM environment created. In some cases, the VMM in blocks 740 and 750is the same VMM, or is a VMM on the same host. For instance, referringto FIG. 5, VMM 530 or VMM 532 may create and execute VM 516 according tothe descriptor and using the data files associated with the descriptor.According to embodiments, if VMM 530 creates VM 516, then VMM 530creates and executes VM 516 on host 500. In some cases, if VMM 532creates VM 516, then VMM 532 creates and executes VM 516 on host 502.

Also, block 740 and/or 750 may be described as resuming a VMenvironment. Thus, block 740 may be omitted (e.g., optional and notperformed for this embodiment) and block 750 may include executing(e.g., resuming) a VM that has already been created (e.g., before block740) according to the information for a descriptor for the previouslycreated VM. For instance, a user can resume an email VM, suspended whenthe host machine is turned off (e.g., by the user, thus, suspending theuser's email VM). Then the VEM can unsuspend or resumed the email VMwhen the host is turned back on (e.g., by the user) starting the emailVM that has already been created before according to the informationstored in the descriptor and the data files for the suspended VM.

At block 760, upon or after a VM environment is executed (instantiatedand “run” or resumed), a VEM manages the VM environment executed. VEMmay management may include use of VEM I/F's and/or VMM management asnoted above. In some cases, the VEM in blocks 760 and 730 may be thesame or different VEMs, or VEMs on the same or different host. Forinstance, referring to FIG. 5, VEM 580 may send the descriptor andcorresponding data files to VMM 532, which creates VM 516 at host 502according to the description information of the descriptor. Once VM 516is created at host 502, VEM 590 may manage VM 516 at host 502 accordingto the management information of the descriptor. According toembodiments, if VMM 530 executes VM 516, then VEM 580 manages VM 516 onhost 500. In some cases, if VMM 532 executes VM 516, then VEM 590manages VM 516 on host 502.

As noted above, process 700 may be performed by the same VEM thatcreates or generates the descriptor to create (or resume) the VMenvironment and/or the same VM that creates or generates the descriptorto manage the VM environment. Alternatively, the description informationto create the VM environment and/or management information to manage theVM environment may be obtained, acquired, or referenced from anotherVEM, such as by accessing a storage device, network, the internet, amemory, etc. It can be appreciated that the ability for different VEMsand VMMs to use or reference descriptors from various hosts and/or otherVEMs to create and/or manage VM environments provides flexibility forcreating VM environments.

Thus, embodiments of the invention allow for flexible and uncomplicatedvirtual environment “manager” (VEM) creation of VM environments and/ormanagement of VM environments on one or more hosts and according todescriptor information referenced, created, or otherwise obtained fromone or more hosts. Note that although a VEM is described as a “manager”,as noted herein, a VEM performs behaviors, functions, processes,creations, resumptions, suspensions, etc., in addition to management ofVM environments.

Further, in some cases, a user may interface, access, provide input,obtain output, and/or communicate with a VEM and/or descriptor using auser interface (e.g., input/output or I/O to the VEM). A user interfacemay be part of hardware 140, such as including a monitor, screen,keyboard, mouse, and/or audio equipment, etc. Also, examples of a userinput may include a “unification console” and/or typical I/Os for VMMenvironments.

Embodiments of the present descriptors, VEMs, and/or VM environments canwork alone or synergistically with a “unification console”, such as aconsole (e.g., where “console” may describe a method, apparatus and/orsystem) that provides for transparently unifying multiple VMs (e.g.,here and in descriptions below, a “VM” may represent a VM environment ora VEM) on a host. More specifically, a unification console on a host maybe dedicated to providing a user with a unified view of multiple VMs onthe host, regardless of the application the user is running or VM inwhich the application is running. In one embodiment the unificationconsole could itself be a VM or a VM environment.

For instance, a unification console may allow for user interaction withapplications, which are running in one or more VMs (other than theunification console itself). The unification console and the VMM (and/orVEM) allow for the redirection of the output of the application toappear on the display of the unification console. Correspondingly theunification console can take user input designated for the applicationand route and deliver it via the VMM (or a direct inter-VM communicationmechanism). The user interface is unified in the sense that the user maybe aware of logical partitioning of resources or domains of operation,but they are not directly aware of the use of virtual machines forsecurely isolating those resources or domains.

Using such a unification console, users may interact with Guest Softwareon a VM host via a unified graphical user interface (the user interfacehereafter referred to as “Unified Desktop Interface 800”). Asillustrated in FIG. 8, the user may be presented with Unified DesktopInterface 800, which is a logical representation of the views of all ora subset of the various VMs on Host 100 such that the user can seeand/or launch applications in one or more VMs from this view. In variousembodiments, the view presented to the user may resemble a typicaldesktop, but unknown to the user, the desktop may in fact representapplications contained in various VMs on the host. In one embodiment,the user's view of Unified Desktop Interface 800 may include allapplications available to the user. Thus, for example, if the user hasaccess to all the VMs on Host 801 (e.g. host 801 may be a host such ashost 100, 200, 500, 502, 600, 602, etc. as described herein) then thevarious applications in each partition may be visible and accessible tothe user in Unified Desktop Interface 800. Alternatively, the user mayonly have permission to access a subset of VMs on the host, in whichcase the applications visible and accessible to the user may includeonly those contained in the authorized VMs. As illustrated, Mail Program810, Audio Visual Program 820 and various other applications (showncollectively as “Other Applications 830”) are presented to the user inthis interface without any indication of which VM these applicationsreside in. In fact, from the user's perspective, there may appear to belittle to no difference between a non-virtualized environment and thevirtualized environment of Host 801 (in which each application iscontained in its own VM).

Unified Desktop Interface 800 illustrated in FIG. 8 is merely an exampleof an interface that the user may see, in which there is no indicationthat the host is virtualized. In an alternate embodiment, UnifiedDesktop Interface 800 may include a view of all the VMs as well as allthe applications running in each VM. In yet another embodiment, in alayered VM environment, a unified desktop interface may exist acrosssome or all VM layers. Alternatively, in a layered VM environment, aunified desktop interface may be provided with each VMM, thus enablingone unified desktop interface to be embedded in the unified desktopenvironment of a parent VM layer. Hybrids of layering of unifieddesktops and/or interleaving of unified desktops are permitted.

Various other unified desktop interfaces may be implemented withoutdeparting from the spirit of embodiments of the present invention. Mostimportantly, by presenting a unified view to the user, embodiments ofthe present invention significantly improve the usability of multipleVMs simultaneously, because the user's experience may resemble that of atypical desktop PC user, namely one in which the user simply selects anapplication (i.e., Guest Software) on Host 801 to execute, withoutneeding to be aware of the virtual partitions on the PC and/or how tomanage or exchange the Guest Software files within these partitions.Thus, for example, if the user selects Mail Program 810, as expected,the user may then be presented with the graphical output (“Mail ProgramOutput 910”) from Mail Program 810, as illustrated in FIG. 9. The usermay view this output within Unified Desktop Interface 800 and theunderlying interaction with the various VMs on Host 801 may remaininvisible to the user, i.e., the user does not know that Mail Program810 is actually executing in one of the VMs on Host 801.

Although invisible to the user, various elements on Host 801 enable theuser to view and/or interact with all the VMs on Host 801 via UnifiedDesktop Interface 800. More specifically, in various embodiments of thepresent invention, a “unification console” (described in further detailbelow) enables the unified interface by transparently redirecting theinput and/or output from the user and the VMs such that the user doesnot have to know which VM an application resides in and/or is runningin. For the purposes of this specification, input and/or output shallinclude any form of input and/or output that Host 801 may recognize.Thus, although “input” herein implies that it is a keystroke, a mouseclick or mouse movement provided by the user, it may in fact include anyother input design that Host 801 is capable of receiving. Similarly,although “output” is described herein as primarily being visual output,embodiments of the present invention are not so limited. Output maytherefore include other types of output, such as audio output.

In one embodiment, a dedicated VM on Host 801 may be designated to runthe unification console with access to all the VMs on Host 801. FIG. 10illustrates conceptually how the unification console (“UnificationConsole 1000”) functions to present Unified Desktop Interface 800 to theuser. Host 801 includes VM 2100 having guest OS 2110, and descriptors1050. VM 2100 and/or guest OS 2110 may be a VM and/or guest OS asdescribed above for VM 110 and/or guest OS 151 of FIG. 1. Also,descriptors 1050 may be a descriptors as described above for descriptors250, 550 and 552)

In FIG. 10 Unification Console 1000 is illustrated as a separatecomponent from the VMM (“Enhanced VMM 1030,” which may be an enhancedVMM such as enhanced VMM 230 of FIG. 2, which includes a VEM running onthat VMM). In some cases, Unification Console 1000 may be a speciallyprivileged VM running on a VMM. However, embodiments of the inventionare not so limited. Instead, in one embodiment, Enhanced VMM 1030 mayinclude all the functionality of Unification Console 1000 while in analternate embodiment, Unification Console 1000 may be a component thatworks in conjunction with Enhanced VMM 1030 (e.g., in an embodiment,Unification Console 1000 may comprise an enhanced VM capable ofaccessing all the other VMs on Host 801). In various embodiments, inputand/or output from the user and/or the VMs (e.g., VM 2100 or other VMsnot shown) may be received by Enhanced VMM 1030 and passed on toUnification Console 1000 for processing. For instance, user input 1001may be received by VM 2100 from unification console 1000, and user input1002 may be received by VM 2100 from hardware 140. Also, VM output 2102may be received by unification console 1000 from VM 2100, and VM output2101 may be received by hardware 140 from VM 2100. It will be readilyapparent to those of ordinary skill in the art that Unification Console1000, hosts, descriptors, VM environments, and VEMs, as described hereinmay be implemented in software, hardware, firmware and/or anycombination thereof. Additionally, Enhanced VMM 1030 may include variousenhancements over existing VMMs, either to include the functionality ofUnification Console 1000 and/or to interact with Unification Console1000. It will be readily apparent to those of ordinary skill in the artthat Enhanced VMM 1030 may also be implemented in software (e.g., as astandalone program and/or a component of a host operating system),hardware, firmware and/or any combination thereof.

Conventional virtual machine usages and architectures encourage andpreserve the separation and isolation features offered by VMs. Thesefeatures are very useful in data center operations (e.g. servers,workstations, and mainframes). However, for the desktop PC and home PC,this usage model may prove difficult because end users are likely to beconfused by the VM concept and to misunderstand separate (isolated)creation/usage/management methodology. Embodiments of the descriptors,VEMs, VM environments, and/or unification console offer the benefits ofVM technology in a more user-transparent manner.

Embodiments of the descriptors, VEMs, VM environments, and/orunification console provide a method for creating and managingcollections of disparate VMs to present a more monolithic environment(and therefore more comprehensible, especially to an end user) view ofthe underlying machine. This includes a unified, single sign-onauthentication, such as to allow a user to use a unification console toaccess a VEM (and, therefore, a set of VMs, OSes, and applications) andto specify or select separate host environment management policies(e.g., create and or change descriptor information, data fileinformation, constrained facet information and/or extended facetinformation) for a VM, a user, a host, a home desktop computer, a laptopcomputer, and/or a work computer.

Embodiments of the descriptors, VEMs, VM environments, and/orunification console permit end users or IT to administer, distribute andshare (or designate) of collections of VM environment descriptors and/orVM environments, or descriptions of those collections. This facilitatescollaborative computing uses as well.

Embodiments of the descriptors, VEMs, VM environments, and/orunification console address the issue that end users may be confused bythe VM concept and separate (isolated) usage/management methodology.Consider a home PC used by a family or a desktop PC in the enterprise.Each family member/user may have one or more virtual machines with theircustomized environments, there may be gaming VM, Personal Video Recorderappliance VMs, enterprise IT-supplied VMs for telecommuting, etc.Creating and/or managing and orchestrating the movement of virtualmachines, files, access permissions, and usages may be overwhelming forthe average user.

Embodiments of the descriptors, VEMs, VM environments, and/orunification console may increase the adoption rate of service platformsand grid computing on the desktop, both in the enterprise and in thehome, because the complexity of these partitions can be hidden orexposed as needed. Software stacks can be bundled into stabledistribution units or images (e.g., into stable descriptors, VMenvironments, and/or host environments). Using this kind of technology,the stable distribution units can be pushable or pullable as a morecentralized and limited bundled of software than without the console,descriptors, and/or VEMs. IT departments then, for example, can pushthese out to their corporate users both at the office and for home useas well. Stable contours or collections can, for instance, be determinedthrough both purposeful construction and/or experimentation. Becausethese VM image units execute in isolated partitions, the barrier foradoption of massive grid computing and the distribution ofservice-oriented VM images could be lowered and become ubiquitous. Themanagement partition (e.g., a VEM) plays the matchmaker, but also canhave additional policies (e.g., management policies) that ensure properload balancing and enforcement of local autonomy.

The hosts, descriptors, VM environments, and VEMs, according toembodiments of the present invention may be implemented on a variety ofcomputing devices, such as where host 100, 200, 500, 502, 600, 602, 801and/or another host is a PC or is a computer server (e.g., a server toservice one or more client computers). According to an embodiment of thepresent invention, computing devices may include various componentscapable of executing instructions to accomplish an embodiment of thepresent invention. For example, the computing devices may include and/orbe coupled to at least one machine-accessible medium. As used in thisspecification, a “machine” includes, but is not limited to, anycomputing device with one or more processors. As used in thisspecification, a machine-accessible medium includes any mechanism thatstores and/or transmits information in any form accessible by acomputing device, the machine-accessible medium including but notlimited to, recordable/non-recordable media (such as read-only memory(ROM), random-access memory (RAM), magnetic disk storage media, opticalstorage media and flash memory devices), as well as mechanical,electrical, optical, acoustical or other form of propagated signals(such as carrier waves, infrared signals and digital signals).

According to an embodiment, a computing device may include various otherwell-known components such as one or more processors. Thus, thecomputing device (e.g., a host, descriptors, VM environments, and VEMs,)may include any type of processor capable of executing software,including microprocessors, multi-threaded processors, multi-coreprocessors, digital signal processors, co-processors, reconfigurableprocessors, microcontrollers and/or any combination thereof. Theprocessors may be arranged in various configurations such as symmetricmulti-processors (e.g., 2-way, 4-way, 8-way, etc.) and/or in othercommunication topologies (e.g., toroidal meshes), either now known orhereafter developed. The term “processor” may include, but is notnecessarily limited to, extensible microcode, macrocode, software,programmable logic, hard coded logic, etc., capable of executingembodiments of the present invention.

The processor(s) and machine-accessible media may be communicativelycoupled using a bridge/memory controller, and the processor may becapable of executing instructions stored in the machine-accessiblemedia. The bridge/memory controller may be coupled to a graphicscontroller, and the graphics controller may control the output ofdisplay data on a display device. The bridge/memory controller may becoupled to one or more buses. One or more of these elements may beintegrated together with the processor on a single package or usingmultiple packages or dies. A host bus controller such as a UniversalSerial Bus (“USB”) host controller may be coupled to the bus(es) and aplurality of devices may be coupled to the USB. For example, user inputdevices such as a keyboard and mouse may be included in the computingdevice to provide input data. In alternate embodiments, the host buscontroller may be compatible with various other interconnect standardsincluding PCI, PCI Express, FireWire and other such current and futurestandards.

In the foregoing specification, embodiments of the invention have beendescribed with reference to specific exemplary embodiments thereof. Itwill, however, be appreciated that various modifications and changes maybe made thereto without departing from the broader spirit and scope ofthe invention as set forth in the appended claims. The specification anddrawings are, accordingly, to be regarded in an illustrative rather thana restrictive sense.

1-30. (canceled)
 31. At least one storage system capable of being usedin association with at least one server, software, and at least onenetwork, the at least one storage system comprising: the mass storagearray comprising at least one storage volume embodied in multiplestorage device types; the at least one server being capable ofexecuting, at least in part, the software; the mass storage array beingcapable of being managed, at least in part, by at least one module, viathe at least one network, when the at least one module is executed, theat least one module being included in the software; the software whenexecuted, at least in part, being capable of managing, at least in part,virtual machines establishable, at least in part, by at least onevirtual machine monitor; the software, when executed, at least in part,being capable of providing, at least in part, a single respectivesign-on authentication, to permit access to resources of multiple of thevirtual machines; the software, when executed, at least in part, beingcapable, at least in part, of receiving at least one request forestablishment of at least one clone of at least one of the virtualmachines; the software, when executed, at least in part, being capable,at least in part, of receiving at least one request for modification, atleast in part, of the at least one clone; the modification being relatedto, at least in part, a guest operating system and networking of the atleast one clone.
 32. The at least one storage system of claim 31,wherein: the mass storage array comprises a disk array.
 33. The at leastone storage system of claim 31, wherein: the at least one storage systemis to be used in association with grid computing.
 34. The at least onestorage system of claim 31, wherein: the software comprises softwarecomponents to provide, at least in part, the single respective sign-onauthentication, and to permit, at least in part, the access to theresources.
 35. The at least one storage system of claim 34, wherein: thesoftware components and the at least one software module are notcomprised, at least in part, in the at least one virtual machinemonitor.
 36. The at least one storage system of claim 31, wherein: thesoftware, when executed, is capable of receiving at least one requestfor establishment, at least in part, of at least one management policyrelated to the managing; and the at least one policy is to beimplemented, at least in part, using at least one descriptor.
 37. The atleast one storage system of claim 34, wherein: the at least onedescriptor is associated, at least in part, with at least one of virtualmachine provisioning and virtual machine creation.
 38. The at least onestorage system of claim 31, wherein: the multiple of the virtualmachines are to be executed, at least in part, by multiple computingdevices; and the multiple computing devices comprise multi-coremicroprocessors.
 39. The at least one storage system of claim 31,wherein: the establishment of the at least one clone is to be based, atleast in part, upon at least one descriptor that describes, at least inpart, the at least one clone.
 40. The at least one storage system ofclaim 31, wherein: the modification of the at least one clone is to beassociated, at least in part, with modification, at least in part, ofthe at least one descriptor by the software.
 41. The at least onestorage system of claim 31, wherein: the software, when executed, iscapable, at least in part, of providing, at least in part, at least onemanagement console that is capable, at least in part, of receiving therequests.
 42. The at least one storage system of claim 31, wherein: theat least one server comprises a keyboard, mouse, and display device. 43.The at least one storage system of claim 31, wherein: the mass storagearray comprises flash memory and disk storage.
 44. A system comprising:at least one server, a mass storage array, software, and at least onenetwork; the mass storage array comprising at least one storage volumeembodied in multiple storage device types; the at least one server beingcapable of executing, at least in part, the software; the mass storagearray being capable of being managed, at least in part, by at least onemodule, via the at least one network, when the at least one module isexecuted, the at least one module being included in the software; thesoftware when executed, at least in part, being capable of managing, atleast in part, virtual machines establishable, at least in part, by atleast one virtual machine monitor; the software, when executed, at leastin part, being capable of providing, at least in part, a singlerespective sign-on authentication, to permit access to resources ofmultiple of the virtual machines; the software, when executed, at leastin part, being capable, at least in part, of receiving at least onerequest for establishment of at least one clone of at least one of thevirtual machines; the software, when executed, at least in part, beingcapable, at least in part, of receiving at least one request formodification, at least in part, of the at least one clone; themodification being related to, at least in part, a guest operatingsystem and networking of the at least one clone.
 45. The system of claim44, wherein: the mass storage array comprises a disk array.
 46. Thesystem of claim 44, wherein: the mass storage array is to be used inassociation with grid computing.
 47. The system of claim 44, wherein:the software comprises software components to provide, at least in part,the single respective sign-on authentication, and to permit, at least inpart, the access to the resources.
 48. The system of claim 44, wherein:the software components and the at least one software module are notcomprised, at least in part, in the at least one virtual machinemonitor.
 49. The system of claim 44, wherein: the software, whenexecuted, is capable of receiving at least one request forestablishment, at least in part, of at least one management policyrelated to the managing; and the at least one policy is to beimplemented, at least in part, using at least one descriptor.
 50. Thesystem of claim 44, wherein: the at least one descriptor is associated,at least in part, with at least one of virtual machine provisioning andvirtual machine creation.
 51. The system of claim 44, wherein: themultiple of the virtual machines are to be executed, at least in part,by multiple computing devices; and the multiple computing devicescomprise multi-core microprocessors.
 52. The system of claim 44,wherein: the establishment of the at least one clone is to be based, atleast in part, upon at least one descriptor that describes, at least inpart, the at least one clone.
 53. The system of claim 44, wherein: themodification of the at least one clone is to be associated, at least inpart, with modification, at least in part, of the at least onedescriptor by the software.
 54. The system of claim 44, wherein: thesoftware, when executed, is capable, at least in part, of providing, atleast in part, at least one management console that is capable, at leastin part, of receiving the requests.
 55. The system of claim 44, wherein:the at least one server comprises a keyboard, mouse, and display device.56. The system of claim 44, wherein: the mass storage array comprisesflash memory and disk storage.